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EXECUTIVE  SUMMARY 


This  report  focuses  on  Electronic  System  Division's  ( ESD ) 
role  in  prioritizing  command  and  control  (C2)  system  requirements 
during  the  concept  formulation  phase.  Particular  attention  is 
paid  to  this  phase  of  development  because  it  is  during  this  phase 
that  alternative  system  concepts  are  tested  against  user 
requirements  and  key  trade-offs  are  made  between  cost  and 
performance.  Decisions  made  at  this  point  have  an  enormous 
impact  on  user  satisfaction  and  the  ultimate  cost  of  C2  systems. 
The  developer.  Electronic  Systems  Division,  must  thoroughly 
understand  the  system  requirements  and  priorities  in  order  to 
successfully  complete  conceptual  design. 


THE  PROBLEMS  AND  FINDINGS 


All  too  often,  ESD  finds  that  it  does  not  adequately 
understand  the  system  requirements  and  priorities  of  C2  systems. 
This  happens  because  the  developer  is  performing  a  number  of 
functions  at  the  same  time  and  is  attempting  to  coordinate 
requirements  with  many  different  organizations.  In  some 
instances,  the  developer's  functions  are  both  complimentary  and 
contradictory.  To  more  clearly  understand  the  developers's  tasks 
in  prioritizing  system  requirements,  a  distinction  is  made 
between  the  developer's  role  as  purchasing  agent  and  the 
developer's  role  as  supplier. 
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As  a  purchasing  agent,  the  developer  is  attempting  to 


acquire  the  best  value  by  balancing  requirements  to  minimize 
total  expenditures.  This  function  involves  many  participants, 
all  with  specialized  knowledge  and  conflicting  interests.  The 
user,  who  is  the  prime  originator  of  requirements,  is  concerned 
with  performance.  Other  participants  in  the  requirement  process 
are  mainly  concerned  with  support  requirements.  Given  a  limited 
budget,  some  requirements  conflict.  Many  of  the  participants  in 
the  requirement  process  find  it  easier  not  to  prioritize 
requirements  in  this  environment.  They  prefer  to  let  the 
developer  decide  these  issues.  However,  the  developer  does  not 
have  complete  authority  to  decide.  Any  Judgement  he  makes  is 
subject  to  review  by  the  participants  and  can  be  reversed  or 
delayed  if  a  participant  fights  strongly  enough. 

As  a  supplier,  the  developer  is  confronted  with  a  set  of 
different  issues.  In  this-  case,  the  unique  nature  of  command  and 
control  systems  and  the  traditional  acquisition  structure  make  it 
difficult  for  the  user  to  understand  and  communicate  his 
requirements.  This,  in  turn,  results  in  ill  defined  requirements 
that  are  almost  impossible  to  prioritize.  Because  of  the 
sophisticated  nature  of  command  and  control  technology,  the 
practice  of  using  user  surrogates  to  specify  requirements 
insulates  the  real  user  from  the  technology  that  he  must 
understand.  In  practice,  the  only  effective  way  to  define  C 2 
requirements  is  to  allow  the  real  user  to  react  to  the  technology 
and  iterate  his  requirements  through  "hands  on  experience". 


ill 


Priorities  are  best  determined  through  an  iterative  process  that 
involves  the  real  user,  user  surrogate,  and  the  developer  in  an 
integrated  rather  than  sequential  manner. 


RECOMMENDATIONS 


Recommendation  1 ;  Electronic  Systems  Division  should 


aggressively  use  design  to  cost  and  design  to  life  cycle  cost 
techniques  to  help  prioritize  requirements. 


ESD  has  the  ability  to  determine  rough  fiscal  constraints  by 
using  costs  of  similar  systems  and  assessing  the  political 
environment  to  determine  funding  limits.  Once  a  rough  constraint 
is  established,  ESD  can  employ  design  to  cost  techniques  to 
determine  cost  drivers  for  the  proposed  system.  The  cost  drivers 
then  provide  the  ability  to  challenge  the  participants' 
requirements  and  determine  their  utility.  The  knowledge  of  cost 
combined  with  performance  and  support  considerations  can  then  be 
used  to  prioritize  requirements. 


Recommendation  2:  Electronic  Systems  Division  should  not 


assume  complete  authority  for  determining  requirement  priorities 
at  this  time. 


Much  has  been  said  about  fixing  responsibility  in  the 
acquisition  process.  In  the  case  of  requirement  prioritization, 
ESD  seems  to  have  the  broadest  view  of  all  the  participants' 
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interests  and  is  in  the  most  logical  position  to  assume 
responsibility  for  these  decisions.  However,  assuming  more  of 
this  responsibility  cannot  be  accomplished  unilaterally.  Many 
vested  interests  and  legitimate  concerns  of  the  other 
participants  in  the  requirement  process  will  have  to  be  addressed 
before  this  can  be  accomplished. 

Recommendation  3:  Electronic  Systems  Division  should 

develop  a  rapid  prototyping  capability  to  define  and  prioritize 
user  requirements. 

It  is  apparent  that  the  nature  of  C 2  systems  along  with 
traditional  acquisition  methods  have  prevented  adequate 
expression  of  requirements.  ESD  can  help  solve  this  problem  by 
using  prototypes  installed  at  the  real  user's  location  to 
determine  requirements  and  priorities.  This  approach  provides  a 
better  match  between  the  developer's  technical  expertise  and  the 
real  user's  operational  expertise.  Prototypes  allow  requirements 
to  be  iterated  and  the  developer  can  gain  a  better  understanding 
of  the  real  user's  true  priorities. 


INTRODUCTION 


The  concept  formulation  phase  is  the  most  critical  part 
of  the  acquisition  process.  It  is  during  this  stage  of 
development  that  alternative  concepts  are  tested  against  user 
requirements  and  key  trade-offs  are  made  between  cost  and 
performance.  Up  to  855C  of  the  projected  life  cycle  cost  of  a 
weapon  system  results  from  the  decisions  made  during  conceptual 
design  [13.  If  the  concept  formulation  phase  is  not  completed 
properly,  subsequent  phases  such  as  demonstration  and  test  will 
reveal  deficiencies  ii.  requirements  and  technical  approaches  that 
will  require  substantial  changes  and  result  in  delays  to  the 
program. 

Successful  conceptual  design  rests  on  a  set  of  well 
defined  and  prioritized  system  requirements.  These  requirements 
originate  with  the  user  and  must  be  fully  understood  by  the 
developer.  If  the  developer  does  not  understand  the  user's 
requirements  and  his  priorities,  it  will  be  nearly  impossible  to 
translate  the  requirements  into  meaningful  contractual  language 
in  the  request  for  proposal.  Contractors  rely  on  this 
translation  to  formulate  alternative  system  designs.  Figure  1 
depicts  the  preliminary  steps  of  the  concept  formulation  phase 
and  illustrates  how  concept  definition  depends  on  operational 


requirements. 


As  can  be  seen  in  the  diagram,  the  process  labeled  system 


trade-offs  and  formulation  of  alternative  system  concepts  depends 


on  two  functions  performed  by  the  developer.  First,  the 


developer  must  perform  cost  and  effectiveness  assessments  to  make 


overall  trade-offs  on  system  requirements.  Second  and 


simultaneously,  the  developer  must  perform  a  feasibility 


investigation  of  the  critical  elements  (mostly  performance 


characteristics )  of  the  program.  The  first  function  resembles 


that  of  the  traditional  purchasing  agent.  In  this  case  the 


developer  is  attempting  to  acquire  the  best  value  by  balancing 


requirements  to  minimize  total  expenditures.  The  second  function 


is  more  similar  to  the  role  of  a  supplier  in  the  commercial 


world.  The  developer  is  providing  specific  technical  advice  to 


help  the  user  solve  his  problem.  While  these  two  functions  are 


qualitatively  different,  they  occur  simul taneout. ly  and  both 


require  prioritized  requirements  for  successful  completion. 


Both  the  literature  and  interviews  indicate  that  there  is 


a  clear  lack  of  requirement  prioritization  in  systems 


acquisition  [3],  Electronic  Systems  Division  personnel  have  also 


revealed  that  lack  of  prioritization  results  in  production  of 


command  and  control  <C2)  systems  that  do  not  meet  the  user's 


needs.  As  shown  above,  prioritized  requirements  are  necessary  to 


direct  the  research  and  development  community  during  design 


studies  and  they  assist  in  allocating  scarce  funds  to  the  most 


important  uses  in  a  system.  Given  the  ultimate  impact  on  a 


system's  military  capability  and  cost,  it  is  essential  that 


requirements  be  prioritized.  Without  a  set  of  prioritized 
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requirements,  the  developer  and  contractor  cannot  assess 
alternative  designs  and  produce  a  system  that  meets  the  user's 
needs. 

This  paper  will  analyze  impediments  to  requirement 
prioritization  and  recommend  solutions  that  Electronic  Systems 
Division  <ESD>  can  employ  to  produce  prioritized  operational 
requirements.  The  first  section  of  the  paper  concentrates  on 
requirement  prioritization  and  the  developer's  role  as  purchasing 
agent.  In  this  case,  the  developer  must  examine  both  operational 
performance  requirements  and  operational  suitability 
requirements,  weigh  them  with  respect  to  cost  and  performance, 
and  produce  a  ranking  that  maximizes  overall  utility  of  the 
system.  Here,  the  impediments  to  requirement  prioritization  are 
mainly  institutional  in  nature.  The  second  section  addresses 
requirement  prioritization  and  the  developer's  role  as  supplier. 
In  this  situation,  the  developer  is  attempting  to  help  the  user 
define  and  prioritize  his  performance  requirements  so  these 
requirements  can  be  viewed  in  the  larger  framework  discussed  in 
the  first  section.  The  developer's  role  as  supplier  is 
complicated  by  the  unique  nature  of  command  and  control  systems. 
Furthermore,  institutional  arrangements  also  contribute  to  the 
problem  of  requirement  prioritization.  Approaches  to  the  problem 
and  recommendations  are  presented  at  the  end  of  each  section. 
Finally,  the  conclusion  draws  both  problems  together  and  puts 
them  in  perspective. 


THE  DEVELOPER  AS  PURCHASING  AGENT 


A.  ANALYSIS  OF  THE  PROBLEM 

1 .  Documenting  and  Coordinating  Operational  Requirements 

The  requirement  for  a  new  Air  Force  weapon  system  starts 
when  the  user  identifies  an  operational  deficiency  that  cannot  be 
corrected  "through  changes  in  tactics,  strategy,  doctrine,  or 
training  and  whose  solution  requires  a  new  development  or  upgrade 
of  an  existing  system"  C43.  System  requirements  are  formally 
documented  in  a  Statement  of  Operational  Need  (SON)  which  is 
circulated  in  a  draft  version  to  numerous  Air  Force  agencies  for 
comment . 

Circulation  of  the  draft  SON  is  necessary  to  obtain  a 
broad  Air  Force  perspective  on  a  proposed  system.  Conceptually, 
this  is  a  sound  process.  Inputs  are  not  only  needed  from  the 
people  who  will  operate  the  system,  but  also  from  the  various 
agencies  that  will  deal  with  a  new  system  during  its  life  cycle. 
Many  requirements  must  be  coordinated.  For  example,  testing 
criteria  must  be  established,  maintenance  concepts  formulated, 
logistic  support  planned,  and  manpower  training  requirements 
evaluated.  As  suggested,  this  is  a  huge  planning  task  and  in 
many  instances  is  performed  at  a  grass  roots  level. 

In  total,  18  Air  Force  agencies  or  commands  are  listed  as 
action  addressees  (i.e.  These  organizations  must  make  formal 
comments  on  any  draft  SON)  and  53  organizations  receive  an 
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information  copy  of  the  draft  SON  < See  Attachment  1).  These 
agencies  are  responsible  for  reviewing  the  requirements  listed  in 
the  SON  and  determining  if  the  proposed  system  will  affect  their 
operations.  If  a  new  system  does  affect  an  agency,  it  must 
comment  on  what  the  effect  will  be  and  state  any  constraints  or 
additional  requirements. 

2.  Participants  and  Their  Interests 

In  practice,  circulating  a  draft  SON  helps  prevent  errors 
of  omission  but  it  does  not  prevent  errors  of  commission. 

Because  many  of  the  SON  reviewers  are  grass  roots  workers,  they 
tend  to  have  a  highly  parochial  view  and  do  not  understand  how 
including  some  requirements  affects  the  entire  system. 
Headquarters  Air  Force  reviews  the  draft  SON  and  attempts  to 
reconcile  conflicting  requirements,  but  this  process  occurs 
before  any  significant  information  on  cost  is  obtained. 

Therefore,  many  draft  SON's  still  contain  a  multitude  of 
requirements  promulgated  by  many  different  agencies. 

Getting  all  these  agencies  to  agree  on  a  prioritized  list 
of  requirements  can  be  extremely  difficult.  Not  only  are  many  of 
the  agencies  geographically  disparate,  they  also  have  differing 
functions  and  responsibilities.  The  user  is  mainly  concerned 
with  the  system's  performance  and  how  the  system's  performance 
helps  him  accomplish  his  wartime  mission.  The  support  agencies 
are  concerned  with  an  entity  called  operational  suitability.  The 


operational  suitability  of  a  system  determines  the  level  of 
effort  and  amount  of  resources  that  support  agencies  must  devote 
to  maintaining  a  system. 

At  this  point,  it  is  necessary  to  define  the  military 
worth  of  a  system  and  explain  the  factors  that  influence  this 
measure  of  value.  Military  worth  is  the  overall  utility  of  the 
system,  that  is,  the  degree  to  which  the  system  performs  the 
intended  mission  in  both  peacetime  and  war.  Military  worth 
depends  on  the  operational  performance  and  the  operational 
suitability  characteristics  of  the  system. 

MILITARY  WORTH  =  OPERATIONAL  PERFORMANCE  «-  OPERATIONAL 

SUITABILITY 

Performance  is  a  relatively  straight  forward  concept. 
However,  operational  suitability  is  a  catchall  term  that  includes 
everything  else  that  may  matter  during  a  system's  lifetime. 
Department  of  Defense  Directive  5000.3  defines  operational 
suitability  as,  "The  degree  to  which  a  system  can  be  placed 
satisfactorily  in  field  use,  with  consideration  being  given  to 
availability,  compatibility,  transportability,  interoperability, 
reliability,  wartime  usage  rates,  maintainability,  safety,  human 
factors,  manpower  supportability,  logistic  supportabil ity,  and 
training  requirements"  [5D.  While  performance  is  the  exclusive 
domain  of  the  user,  most  of  the  "ilities"  come  under  the  purview 
of  separate  organizations  created  to  deal  with  subsets  of 
operational  suitability. 
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Conventional  wisdom  dictates  that  the  degree  to  which 
operational  performance  and  operational  suitability  are  factored 
into  the  military  worth  equation  depends  on  the  type  of  system 
and  how  it  is  employed.  However,  the  resulting  balance  can  also 
be  viewed  as  the  outcome  of  a  struggle  between  the  user  and 
organizations  responsible  for  operational  suitability. 

Description  of  two  of  the  participants  in  the  requirement  process 
will  help  illuminate  the  tension  that  exists. 

The  user:  The  user  is  generally  a  major  command  (MAJCOM) 
in  the  Air  Force  with  an  operational  mission  that  requires  C 2 
systems  to  control  its  forces.  Users  include  Strategic  Air 
Command,  Tactical  Air  Command,  Military  Airlift  Command  and  the 
North  American  Defense  Command. 

The  user  is  concerned  with  performance  of  a  new  system 
and  how  increased  performance  will  help  him  accomplish  the 
mission.  For  this  reason  and  also  because  the  user  is  the  prime 
originator  of  the  SON,  requirements  for  operational  performance 
are  emphasized  over  less  understood  operational  suitability 
requii ements.  The  user  can  evaluate  the  military  worth  of 
performance  requirements  and  only  vaguely  comprehends  the  utility 
of  operational  suitability  requirements.  The  user  is  aware  of 
operational  suitability  to  the  extent  that  factors  such  as 
reliability  and  maintainability  affect  the  performance  of  the 
system.  However,  factors  such  as  training  maintenance 
technicians  and  supplying  spare  parts  are  secondary  concerns  in 
the  initial  stages  of  acquisition.  The  user  wants  a  system  that 
will  meet  the  current  and  projected  threat.  In  addition,  because 
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the  user  is  the  one  who  employs  the  system  in  combat,  his  opinion 
generally  receives  more  attention  than  that  of  support 
organizations. 

Air  Force  Logistics  Command:  Air  Force  Logistics  Command 
is  the  organization  that  is  responsible  for  maintaining  systems 
and  correcting  design  deficiencies  once  the  initial  acquisition 
is  complete.  To  a  large  extent,  the  organizational  culture  of 
Logistics  Command  has  been  influenced  by  the  systems  they  have 
maintained.  One  trend  that  has  become  more  pronounced  with  the 
passage  of  time  is  the  increased  service  life  of  weapon  systems 
in  the  Air  Force  inventory  161.  Many  of  these  systems  have  been 
extended  well  past  their  planned  service  life  and  do  not  match 
the  potential  reliability  available  with  new  technology. 
Experience  with  less  reliable  systems  that  have  been  maintained 
well  past  their  expected  service  life  has  made  Air  Force 
Logistics  Command  an  advocate  for  improved  operational 
suitability.  Logistics  Command  bears  most  of  the  cost  of  poorly 
designed  systems.  Retrofit  of  systems  that  do  not  meet  user 
requirements,  that  are  unreliable,  or  that  have  poor 
maintainability  characteristics,  not  only  imposes  financial  costs 
but  also  diverts  scarce  talent  from  other  projects. 
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Although  it  1b  in  the  long  term  interest  of  the  user  to 
acquire  systems  that  are  more  reliable  and  maintainable,  this 
often  does  not  occur  because  of  the  nature  of  defense  funding. 
Congress  votes  separate  funds  for  acquisition  and  for  operations 
and  maintenance.  Acquisition  appropriations  are  highly  visible, 
whereas  operations  and  maintenance  funds  are  costs  that  must  be 
paid  for  equipment  already  in  the  inventory.  Because  the  user  is 
concerned  with  the  performance  necessary  to  meet  a  projected 
threat,  he  is  hesitant  to  include  specific  reliability  and 
maintainability  requirements  for  fear  that  it  will  drive  up  the 
acquisition  cost  of  the  program.  If  these  requirements 
significantly  raise  costs,  a  program  could  be  cancelled  and  the 
user  would  receive  no  new  capability  to  meet  the  threat  [7], 
Logistics  Command  bears  most  of  the  maintenance  costs  of  less 
reliable  systems.  Therefore,  it  fights  for  tougher  reliability 
and  maintainability  requirements.  If  the  conflicting 
requirements  are  prioritized,  then  one  or  both  of  the  parties 
interests  will  be  compromised.  Although  recent  high  level 
policy  guidance  has  attempted  to  internalize  the  costs  of  less 
reliable  and  maintainable  systems,  this  example  is  cited  to 
illustrate  why  many  of  the  costs  of  systems  acquisition  are  not 
internalized.  When  many  actors  enter  the  requirements  process, 
and  all  lay  claim  to  urgent  priorities,  it  is  difficult  to  reach 
an  agreement  on  a  ordered  list  of  requirements. 
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In  the  early  stages  of  the  requirement  process  the  user 
is  the  lead  organization.  The  user  documents  his  requirements  in 
the  Statement  of  Need  and  coordinates  them  with  the  various 
supporting  organizations.  At  this  point,  the  developer's  role  is 
mainly  to  provide  technical  assistance  to  identify  solutions  to 
the  user's  problem.  While  cost  is  a  consideration,  it  is  not 
predominant.  This  is  because  the  user's  currency  of  evaluation 
is  performance  and  trade-offs  are  more  likely  to  be  viewed  from 
this  perspective.  As  the  requirements  process  continues,  the 
developer  begins  to  takeover  as  the  lead  organization.  Stated 
requirements  are  now  viewed  from  the  perspective  of  the  developer 
and  cost  becomes  the  currency  used  to  evaluate  trade-offs.  The 
developer,  however,  never  gains  complete  control  of  the  process. 
He  must  always  proceed  with  the  concurrence  of  the  user. 

When  cost  becomes  a  major  factor  in  trade-off  decisions, 
the  user  is  forced  to  employ  strategies  that  will  help  maintain 
the  performance  orientation  of  the  system's  development.  If  the 
user  adamantly  objects  to  a  trade-off  based  on  cost,  he  can  veto 
the  developer's  decision.  This  approach  is  useful  only  as  a  last 
resort.  If  it  is  over  employed,  the  developer's  support  for  the 
program  wanes  and  relationships  between  the  user  and  developer 
are  stressed.  A  less  threatening  strategy  is  non-prioritization 
of  requirements.  This  strategy  is  a  way  out  of  the  trade-off 
dilemma  because  it  offers  the  hope  that  increased  funding  can  be 
approved  and  trade-off  decisions  based  on  cost  can  be  avoided. 


Non-prioritization  of  requirements  is  a  strategy 
available  to  the  user  (as  veil  as  other  organizations  in  the 
requirements  process)  because  of  the  dual  role  of  the  developer. 
On  the  one  hand,  the  developer  is  responsible  for  providing  the 
engine  ring  and  programmatic  expertise  necessary  to  acquire 
weapon  systems  from  contractors.  In  this  role  the  developer  is 
charged  with  meeting  the  user's  (and  other  organization's) 
requirements.  On  the  other  hand,  the  developer  must  price  the 
system  requirements,  recommend  funding  levels,  and  then  work 
within  funding  levels  approved  by  Headquarters  Air  Force  and 
Congress.  If  the  developer  completely  understands  the  user's 
requirements  and  priorities,  the  user  is  more  vulnerable  to 
funding  instability.  As  the  budget  is  cut,  the  developer  may  be 
less  resistant  to  cuts  in  a  program  that  he  knows  can  be  managed 
with  less  resources  (That  is,  a  program  in  which  the  developer 
will  have  less  difficulty  finding  the  features  to  cut. ). 

This  situation  occurs  whenever  approved  funding  is  less 
than  that  necessary  to  meet  validated  requirements.  The  user  has 
difficulty  appreciating  the  funding  constraint  because  his 
perspective  is  that  he  has  requirements  and  the  requirements  must 
be  met  to  deter  or  combat  the  threat.  Users  feel  that 
prioritization  of  requirements  would  allow  program  managers  to 
delete  the  lowest  priorities  from  a  system  every  time  the  budget 
is  cut  or  technical  difficulties  require  more  unavailable 
resources.  From  the  user's  perspective,  requirements  are  still 
requirements  regardless  of  their  ranking  on  a  list. 


Figure  2  is  included  to  help  illustrate  the  major 


participants  and  their  relationships  in  both  the  requirement 
validation  and  funding  process  for  a  new  weapon  system.  As 
shown,  the  user  has  primary  knowledge  of  the  mission,  operating 
environment,  and  operational  performance  requirements  and  is 
initially  charged  with  developing  the  Statement  of  Need.  The 
various  supporting  commands,  indicated  in  boxes,  understand  the 
operational  suitability  requirements  and  other  support 
requirements  affecting  the  acquisition.  The  developer  has  the 
programmatic  expertise  to  perform  cost  and  technical  assessments 
of  the  system  requirements  and  the  authority  to  procure  the 
system  from  contractors.  Headquarters  Air  Force  reviews  the 
requirements  and  uses  cost  estimates  established  by  the  developer 
to  plan  funding.  Headquarters  also  determines  the  relative 
priority  of  a  system  compared  to  other  systems  competing  for 
funding  and  submits  the  system  for  funding  competition.  Finally, 
Congress  determines  ultimate  program  funding  through  the 
appropriation  process. 
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In  this  depiction,  the  developer  is  In  an  awkward 
position.  He  must  recommend  funding  levels  to  the  Air  Staff,  but 
before  he  can  accomplish  this  task  he  must  understand  the  system 
requirements  and  priorities.  Priorities  are  difficult  to 
establish  because  the  user  and  various  support  commands  recognize 
that  the  developer  is  the  funding  advocate  for  the  system.  The 
user  has  leverage  over  the  developer  because  in  the  scheme  of 
things  the  developer  must  be  responsive  to  the  user's  needs. 

Since  the  user  does  not  have  direct  control  over  funding  he  does 
not  have  the  motivation  to  make  requirement  trade-offs  based  on  a 
funding  constraint.  In  many  instances,  the  user  does  not  even 
have  the  capability  to  assess  the  trade-offs  in  this  manner. 


B.  APPROACHES  TO  THE  PROBLEM 


In  general,  this  process  does  not  adequately  involve 
participants  with  a  sophisticated  knowledge  of  the  cost 
and  schedule  implications  of  technical  improvements 
required  to  satisfy  these  characteristics.  ...  If  users 
understood  the  likely  impact  of  their  requirements  on 
the  schedule,  quantity,  and  maintainability  of  the 
weapons  they  eventually  received,  they  would  have  a 
strong  motivation  for  compromise.  Generally,  however, 
that  compromise--B  conscious  trade-off  between 
performance  and  cost--does  not  take  place  to  an 
adequate  degree.  Implicitly,  it  is  assumed  that 
military  requirements  should  be  "pure"  and  that  any 
necessary  trade-offs  will  take  place  later  in  the 
process  C81. 


Given  this  view,  the  developer  must  find  a  way  to  use  cost  as  a 
method  for  evaluating  requirement  priorities.  Once  this 
information  is  known,  users  and  support  organizations  may  be  able 
to  prioritize  requirements  and  make  the  necessary  trade-offs 
early  in  the  concept  formulation  phase. 

This  problem  has  long  been  recognized  within  the 
Department  of  Defense  and  a  large  amount  of  literature  has  been 
published  on  the  need  to  design  systems  to  a  proposed  budget  or 
cost.  Design  to  cost  is  a  concept  borrowed  from  commercial 
product  development.  In  the  commercial  world  cost  targets  are  a 
function  of  market  demand.  The  commercial  firm  estimates  what 
consumers  are  willing  to  pay  for  a  new  product  with  certain 
features  and  then  uses  this  market  analysis  to  set  a  cost  goal 
for  the  unit  price  of  the  product.  This  provides  the  proper 
incentive  for  the  designers  to  make  appropriate  design  trade-offs 
to  keep  the  cost  of  the  product  on  target.  In  the  defense  world 
this  process  is  reversed.  First,  the  requirements  for  a  new 
system  are  established  and  then  a  cost  for  the  system  is 


established.  Since  the  user  provides  the  market  for  a  system, 
there  is  no  market  risk,  and  the  need  to  produce  at  a  certain 
unit  price  is  not  as  urgent.  In  addition,  since  the  user  does 
not  control  funding  for  his  system  he  does  not  have  the  same  cost 
Incentive  to  perform  trade-offs.  In  general,  the  user  lacks  the 
capability  to  perform  this  trade-off  analysis.  This  makes  him 
more  insistent  on  his  requirements  and  generates  a  lobby  for 
increased  funding. 

The  above  discussion  does  not  imply  that  there  is  a  lack 
of  policy  guidance  mandating  the  need  for  trade-off  analysis  in 
the  requirements  process.  Air  Force  Regulation  57-1  clearly 
states  that  "a  major  element  of  the  requirements  process  is  the 
continual  identification  of  meaningful  performance  trade-offs 
whereby  high-cost  features  providing  only  marginal  performance 
gains  are  deleted  from  the  system"  19 J.  However,  implementation 
of  this  guidance  in  the  earliest  part  of  the  requirements  process 
is  inconsistent.  A  Systems  Management  Acquisition  inspection  of 
requirements  determination  and  validation  observed  a  "...lack  of 
a  clearly  defined,  consistent,  and  well -integrated  pre-SON 
process  for  identifying  and  rationalizing  the  requirement  for  a 
new  or  enhanced  system  and  for  accomplishing  sufficient 
preliminary  system  and  operational  conceptualization  to  assess 
affordability,  plan  necessary  technological  improvements  or 
adaptations,  and  support  a  program  initiation  decision"  [103. 

Both  the  literature  and  interviews  with  ESD  personnel 
suggest  that  there  is  a  tendency  for  the  developer  to  be  overly 
responsive  to  user  requirements.  One  author  stated  that  under 
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the  current  process,  "The  user  develops  requirements,  'throws 
them  over  the  wall'  to  the  developer  and  the  developer  takes  them 
as  gospel"  till.  While  this  is  obviously  an  exaggeration,  it 
echoes  the  thinking  that  requirements  should  be  "pure".  It  also 
highlights  the  need  to  take  an  integrated  approach  to  the 
requirements  process.  The  user,  developer,  and  other  commands 
involved  in  the  requirements  process  must  establish  a  working 
dialog  early  in  the  acquisition  process.  As  mentioned  above, 
each  participant  has  a  certain  expertise  necessary  in  the 
acquisition  of  a  weapon  system.  The  user  knows  what  the  system 
should  do,  the  support  commands  understand  suitability 
requirements,  and  the  developer  has  the  technical  and  financial 
expertise  to  help  reconcile  conflicting  requirements  given  a 
constrained  budget. 

The  developer  can  help  all  the  participants  in  the 
requirement  process  realize  that  they  are  operating  under  a 
constrained  budget.  Resource  boundaries  can  be  estimated  by 
using  costs  of  similar  programs  to  estimate  current  program 
costs.  In  addition,  the  developer  can  assess  the  political 
environment  to  determine  where  the  particular  program  stands  in 
relation  to  overall  Department  of  Defense  and  Congressional 
priorities.  Furthermore,  the  developer  has  the  capability  to 
perform  trade-off  analysis  and  this  analysis  should  be  used  early 
in  the  requirements  process  to  challenge  user  requirements.  In 
this  sense,  design  to  cost  means  identifying  key  cost  drivers  and 
questioning  whether  high  cost  features  are  really  necessary  or 
Just  nice  to  have  items.  It  also  means  assessing  the  level  of  b 
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requirement.  If  the  user  specifies  that  the  computational 
accuracy  of  a  system  must  be  to  nine  significant  digits  and 
current  technology  can  only  provide  accuracy  to  five,  then  this 
requirement  is  subject  to  challenge  on  the  basis  that  pushing  the 
technology  to  meet  the  requirement  will  incur  increased  cost  and 


risk. 


The  point  of  identifying  cost  drivers  is  not  to  force  the 


user  to  accept  current  technology  or  reduce  his  requirement  when 
the  requirement  is  necessary  to  meet  the  threat.  Only  the  user 
can  provide  a  Judgment  on  the  utility  of  a  requirement.  The  goal 
of  this  analysis  is  to  inform  the  user  of  the  cost  implications 
of  his  requirement  and  allow  him  to  re-evaluate  his  requirement 
in  light  of  the  new  information.  This  is  a  subtle  argument  with 
which  many  users  may  take  issue.  However,  the  fact  remains  that 
users  often  employ  conservative  assumptions  in  their 
calculations.  While  this  is  prudent,  it  sometimes  results  in  an 
aggregate  outcome  that  is  many  times  more  conservative  thBr  each 
individual  assumption  C12]. 

Design  to  cost  works  best  when  the  user  clearly  perceives 
a  real  resource  constraint.  Conditions  that  are  favorable  for 
using  design  to  cost  to  prioritize  requirements  occur  when  the 
user  needs  a  system  in  a  relatively  short  period  to  meet  an 
immediate  threat.  In  this  case,  the  user  does  not  have  time  to 
lobby  for  increased  funding  and  he  must  make  do  under  the  current 
resource  constraint.  Design  to  cost  is  also  a  helpful  technique 


19 


in  discerning  the  user's  priorities  when  it  is  apparent  that 
political  constraints  will  prevent  funding  beyond  a  certain 
level. 

Identifying  requirements  that  drive  cost  will  not  be  a 
complete  panacea  in  the  effort  to  get  users  to  prioritize  all 
requirements,  but  it  will  reveal  which  high  cost  requirements  the 
user  thinks  he  must  have  in  order  to  perform  his  mission.  In 
addition,  this  type  of  design  to  cost  is  likely  to  aid  in 
prioritizing  operational  performance  requirements,  but  it  will  be 
less  useful  in  prioritizing  total  system  requirements. 

In  order  to  establish  an  overall  view  of  the  priority  of 
both  operational  performance  requirements  and  operational 
suitability  requirements  it  is  necessary  to  expand  the  design  to 
cost  concept  from  one  of  designing  to  production  cost  to  one  of 
designing  to  life  cycle  cost.  Used  during  the  requirements 
process,  design  to  life  cycle  cost  would  identify  cost  drivers 
based  on  their  contribution  to  both  production  cost  and  overall 
ownership  cost  (this  includes  operations  and  maintenance  costs). 
This  concept  integrates  all  participants  in  the  requirements 
process  and  helps  all  parties  understand  the  relationship  of 
their  requirements  to  total  system  cost.  Identification  of  key 
cost  drivers  early  in  the  requirements  process  can  help  the  user 
and  support  commands  formulate  alternative  ways  to  meet  a 
requirement  at  a  lower  cost. 


2. 


Mandate  Minimum  Quantities 


Design  to  cost  and  design  to  life  cycle  cost  are 
techniques  that  the  developer  can  employ  to  get  a  better 
understanding  of  the  requirement  priorities.  However,  these 
techniques  may  not  be  enough.  As  shown  in  figure  2,  the  user, 
developer,  supporter,  and  trainer  all  interact  in  the 
requirements  process.  While  the  user  generally  has  the  upper 
hand  in  the  relationship  because  he  is  the  final  judge  of  the 
military  worth  of  a  system,  all  of  these  participants  have  a 
horizontal  relationship  to  each  other  with  no  participant  in 
complete  control. 

Another  way  must  be  devised  to  make  all  the  participants 
realize  there  is  a  resource  constraint.  Dr.  Jacques  S.  Gansler, 
former  Deputy  Assistant  Secretary  of  Defense  for  Material 
Acquisition,  has  suggested  that  one  way  to  harmonize  the 
con^Mc+ing  interests  is  to  get  the  participants  to  agree  on  an 
at  lute  minimum  quantity  of  the  system  necessary  to  meet  the 
threat  [133.  Once  quantity  is  established  as  a  firm  requirement, 
it  becomes  inviolate  and  other  requirements  will  fall  into 
place.  Mandating  a  minimum  quantity  eventually  relates  to  a 
rough  fiscal  constraint  and  trade-offs  between  other  requirements 
and  levels  of  requirements  can  be  made  in  this  context. 

This  approach  makes  sense,  but  minimum  quantities  are 
rarely  explicitly  agreed  upon.  Commitment  to  a  minimum  quantity 
is  difficult  for  the  developer  because  reduction  in  quantity  is 
the  program  manager's  ultimate  fall  back  if  the  user  will  not 


make  the  appropriate  trade-offs  in  requirements.  In  addition,  if 


program  uncertainties  compound  to  cause  unexpected  costs 
flexibility  in  the  quantity  of  a  system  procured  may  be  the  only 
solution. 

3.  Fix  Authority  for  Determining  Priorities 

Even  if  all  the  participants  recognize  a  valid  resource 
constraint,  this  still  may  not  be  enough  to  elicit  priorities. 

The  Packard  Commission  assumes  that  all  participants  will  react 
rationally  to  information  on  cost.  However,  the  fact  remains 
that  different  costs  accrue  to  different  participants.  It  may  be 
rational  for  all  the  participants  to  insist  on  requirements  that, 
by  themselves,  only  marginally  increase  total  cost.  The  result 
is  that  the  sum  of  all  the  small  increases  in  cost  dramatically 
raises  the  price  of  the  system.  Moreover,  it  is  not  clear  whose 
requirements  should  receive  greater  priority  and  reconciliation 
of  these  issues  may  only  be  possible  by  vesting  authority  to  make 
decisions  in  a  single  body. 

The  Defense  Science  Board  came  to  a  similar  conclusion  in 
a  1986  study  entitled  "Practical  Functional  Performance 
Requirements".  This  study  recognized  the  conflict  between  the 
participants  responsible  for  operational  suitability  and  the 
user's  desire  for  performance.  The  Defense  Science  Board 
determined  that  the  program  manager  (a  member  of  the  developer's 
organization)  is  best  able  to  determine  priorities.  The  board 
stated,  "the  need  for  specialized  external  review  staffs  can  be 
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reduced  by  assigning  the  program  manager  responsibility  for  the 
'ilities'  in  the  requirements  document..."  tl4J.  This  conclusion 
makes  sense  because  only  the  program  manager  has  the  capability 
to  view  requirements  from  all  angles.  The  program  manager  must 
coordinate  requirements  with  all  the  participants  plus  he  and  his 
staff  have  both  the  technical  expertise  and  financial  capability 
to  understand  how  requirements  interact. 


C.  RECOMMENDATIONS 


The  preceding  section  analyzed  two  general  approaches  to 
help  prioritize  requirements  when  many  actors  are  involved  in  the 
requirement  process.  The  first  approach  centered  on  making  the 
participants  realize  the  cost  implications  of  their  requirements 
and  elicit  priorities  with  this  information.  The  second  approach 
recognized  that  even  with  cost  information,  it  still  may  be 
difficult  to  get  all  the  participants  to  agree  on  a  prioritized 
list  of  requirements.  In  this  case,  the  use  of  a  unitary 
decision  maker  was  suggested. 


Recommendation  1 :  Electronics  System  Division  should  concentrate 
on  techniques  that  will  help  all  the  participants  in  the 


requirements  process  consider  cost  in  determining  requirement 
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ESD  has  the  capability  to  use  design  to  cost  and  design 
to  life  cycle  cost  techniques  to  elicit  requirement  priorities. 
While  use  of  these  techniques  in  the  concept  formulation  phase 
may  be  limited  to  identifying  cost  drivers,  this,  in  itself,  goes 
a  long  way  in  determining  the  proper  system  trade-offs.  ESD 
should  also  adopt  a  policy  of  making  a  minimum  quantity  an 
absolute  requirement.  In  many  instances,  a  minimum  quantity 
equates  to  a  rough  performance  requirement  and  other  user 
requirements  can  then  be  rank  ordered  with  this  information. 

Recommendation  2;  ESD  should  not  attempt  to  give  program 
managers  more  authority  to  determine  requirement  priorities  at 
this  time. 

Program  managers  are  best  situated  to  determine 
requirement  priorities.  However,  ESD  does  not  have  the  authority 
to  institute  this  change.  Participants  in  the  requirements 
process  may  see  this  move  as  an  attempt  by  the  developer  to  usurp 
program  authority.  Furthermore,  while  recommending  this  change, 
the  Defense  Science  Board  concedes  that  it  will  require  Secretary 
of  Defense  support  [153.  Giving  program  managers  more  authority 
to  prioritize  requirements  is  a  goal  that  must  be  pursued  within 
a  broader  context  of  acquisition  reform.  For  now  program 
managers  will  have  to  rely  on  their  persuasive  skills  to  reach 
agreement  on  priorities.  By  employing  design  to  cost  and  design 
to  life  cycle  cost  techniques,  program  managers  will  be  in  an 


improved  bargaining  position  via  a  vis  other  participants  in  the 
requirement  process. 
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THE  DEVELOPER  AS  SUPPLIER 
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A. 


ANALYSIS  OF  THE  PROBLEM 


I 


Up  to  this  point,  the  problems  of  C 2  acquisition  have 
been  addressed  on  a  traditional  level.  That  is,  most  of  the 
impediments  to  requirement  prioritization  stem  from  institutional 
arrangements,  the  requirements  of  the  system  are  assumed  to  be 
knovn  and  relatively  static,  and  the  task  for  ESD  is  to  devise  a 
system  to  harmonize  the  various  interests  in  the  acquisition 
process. 

This  section  deals  with  quite  another  problem  that 
prevents  requirement  prioritization.  The  user  does  not  know  or 
cannot  communicate  his  requirements.  On  the  one  hand,  the  user 
understands  the  operational  environment,  but  he  does  not 
understand  C2  technology  well  enough  to  employ  its  potential.  On 
the  other  hand,  the  developer  knows  what  C2  technology  can  do, 
but  he  does  not  understand  the  user's  environment  well  enough  to 
define  and  prioritize  system  requirements  C163.  This  problem 
usually  occurs  when  a  user  is  automating  his  command  and  control 
system  for  the  first  time,  but  it  also  happens  when  he  is 
attempting  a  significant  conversion  of  an  old  system  and 
replacing  it  with  state  of  the  art  technology.  In  both  cases, 
requirement  prioritization  is  hindered  by  three  factors.  First, 
the  user  does  not  understand  the  technology.  Second,  C2 
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technology  Is  evolutionary  In  nature  and  requirements  change  as 
learning  occurs.  Third,  a  traditional  acquisition  approach 
retards  the  learning  process. 


1.  Users  Do  Wot  Understand  the  Technology 

The  pace  of  computer  and  communications  technology  is 
moving  so  rapidly  that  it  remains  the  exclusive  domain  of  the 
technologist.  Officers  facing  the  daily  pressure  of  command 
simply  do  not  have  the  time  to  learn  the  technical  aspects  of  the 
systems  they  need  for  command  and  control.  Furthermore,  many 
senior  commanders  spent  their  formative  years  using  less 
sophisticated  command  and  control  systems  to  perform  their 
mission.  While  these  users  understand  the  operational  need  for 
command  and  control  systems,  they  simply  do  not  have  the 
capability  to  evaluate  system  level  issues.  This  is  a  pressing 
concern  because  design  issues  such  as  distributed  data  base 
management  and  nodal  versus  fail-soft  systems  make  a  large 
difference  how  the  system  is  employed  and  more  importantly  hov  it 
operates  in  var.  An  Armed  Forces  Communications  and  Electronics 
Association  ( AFCEA )  study  stated: 


A  more  severe  "cultural"  (or  language)  barrier  exists 
between  users  and  providers  of  C2  systems  than  exists 
between  users  and  providers  of  ships,  tanks,  missiles, 
airplanes--f or  weapon  systems,  the  user  can  relate  to 
the  meaning  of  a  more  maneuverable  fighter  plane,  or  a 
more  accurate  or  longer  range  air-to-air  missile,  and 
can  visualize  the  potential  impact  on  mission 
performance  more  easily.  Trying  to  understand,  for 
example,  what  distributed  microprocessor  technology 
might  mean  to  his  ability  to  command  and  control  is 
substantially  more  difficult,  unless  the  user  has  had 
meaningful  past  experience  with  automated  decision 
aids  l 173 . 


Uniqueness  and  Evolutionary  Nature  of  C2  Technology 


C2  systems  are  uniquely  different  from  traditional 
weapons  systems.  C2  systems  are  "mind"  extenders  not  "muscle”  or 
•sense"  extenders.  C2  systems  support  the  commander's  decision 
process  and  as  such  the  commander  and  his  staff  are  an  integral 
part  of  the  system.  Not  only  are  C2  systems  highly  software 
intensive,  but  the  software  must  interact  with  the  cognitive 
process  of  the  commander  and  his  staff  [183. 

This  interaction  necessitates  learning  in  the 
requirements  process.  As  the  user  discovers  the  potential  of  new 
C2  technology,  he  may  envision  new  ways  to  command  his  forces. 
This  leads  to  changes  in  procedures  and  concepts  of  operation  and 
then  feeds  back  into  the  requirements  process.  As  the  user 
learns  by  operating  the  system,  his  requirements  change. 
Therefore,  a  system  built  on  pre-specif led  requirements  may 
become  rapidly  obsolete  if  the  user  has  not  had  the  opportunity 
to  react  the  technology  and  modify  requirements  before  the  system 
is  developed  C193.  Due  to  the  nature  and  complexity  of  C2 


technology,  the  user  must  gain  hands  on  experience  to  define  and 
prioritize  his  requirements  [20].  Without  this  experience, 
learning  will  occur  only  when  a  final  product  is  delivered. 
Refinements  at  this  point  are  not  only  expensive,  but  disrupt 
system  operation  and  degrade  war  fighting  capability. 


3.  Problems  Created  by  the  Traditional  Acquisition  Structure 


The  traditional  acquisition  structure  compounds  problems 
of  user  learning  by  preventing  the  developer  from  establishing  a 
true  customer /supplier  relationship  with  the  user  [21].  Under 
the  traditional  structure,  the  using  commands  have  created 
planning  organizations  to  study  requirements  and  develop  force 
employment  concepts  for  new  systems.  These  organizations  are 
normally  responsible  for  generating  Statements  of  Need  and  system 
concept  of  operations.  This  arrangement  has  worked  relatively 
well  with  systems  that  are  well  understood  and  incremental  in 
nature.  The  concept  of  operations  in  these  systems  does  not 
readily  change  and  the  planning  organization  can  easily  specify 
requirements  based  on  past  procedures.  In  aircraft  acquisition 
for  example,  increased  range,  speed,  and  payload  translates 
easily  into  requirements  and  the  expected  increase  in  capability 
fits  in  nicely  with  current  force  employment  concepts. 
Requirements  for  these  systems  are  relatively  stable  and 
predictable. 
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C2  systems  do  not  enjoy  stable  and  predictable 
requirements.  In  this  case,  the  planning  organization  becomes  a 
barrier  between  the  developer  and  the  real  user  [221.  While  the 
planning  organization  acts  as  a  user  surrogate  and  frees  the  user 
to  perform  his  daily  tasks,  it  also  insulates  the  real  user  from 
the  very  technology  that  he  must  understand.  The  planning 
organization  becomes  the  main  link  to  the  developer.  The  result 
is  that  most  of  the  technical  expertise  of  the  user  is  centered 
in  the  user  surrogate.  When  the  developer  produces  detailed 
design  studies,  it  is  the  user  surrogate  who  reads  them.  The 
real  user  generally  has  neither  the  time  nor  capability  to 
understand  the  advice  of  the  developer  C231.  The  user  surrogate 
does  attempt  to  keep  the  real  user  abreast  of  developments,  but 
without  a  flesh  and  blood  system  to  react  to  the  real  user  is  not 
inclined  to  change,  or  think  about  changing,  his  operating 
procedures.  When  the  C2  system  is  finally  delivered  it,  does  not 
meet  the  real  user's  expectations.  The  end  result  is  that  the 
real  user  must  adapt  his  procedures  and  concept  of  operations  to 
the  new  system  instead  of  evolving  both  the  system  and  procedures 
together. 

Another  drawback  of  the  user  surrogate  is  also  unique  to 
C2  acquisition.  C2  systems  cross  service  boundaries  and  must  be 
capable  of  interoperation  with  a  multitude  of  other  C2  systems. 
The  user  surrogate  is  typically  service  oriented  and  may  not 
adequately  consider  the  real  user's  interservlce  role  when 
producing  requirements  [241.  Again,  this  problem  is  recognized 
and  guidance  explicitly  directs  all  participants  in  the 


requirements  process  to  address  the  Interoperability  issue  [253. 
However,  the  fact  remains  that  the  interoperability  requirements 
are  not  adequately  articulated.  In  many  cases,  only  the  real 
user  understands  the  interoperability  issue  well  enough  to 
express  it  in  the  requirements  process  C26J. 


B.  AN  APPROACH  TO  THE  PROBLEM 

1 .  Use  Prototypes  to  Define  and  Prioritize  Requirements 

Three  things  are  apparent  from  the  preceding  section. 
First  any  attempt  to  define  and  prioritize  C2  system  requirements 
must  start  with  the  real  user.  Second,  the  real  user  must  be 
educated  so  that  he  can  communicate  his  requirements.  Third,  the 
developer  and  the  real  user  (along  with  the  user  surrogate)  must 
be  wedded  in  a  relationship  that  iterates  requirements  and 
promotes  the  transfer  of  Information  between  all  parties. 
Fortunately,  prototyping  is  available  to  assist  with  all  three  of 
these  problems. 

Precisely  because  C 2  systems  involve  a  very  real  human 
element,  operational  prototypes,  e '  >rcised  in  the  user's 
environment  are  the  best  way  to  define  and  prioritize  system 
requirements.  Many  C2  systems  have  been  developed  off-line  to 
the  user  and  have  not  integrated  the  personnel  and  procedural 
aspects  of  the  real  user's  organization.  This  method  of 
acquisition  resulted  in  numerous  C2  failures  and  will  continue  to 


threaten  failure  for  future  systems  C 271.  Operational  prototypes 
can  correct  this  problem.  If  operational  prototypes  are 
employed,  the  user  will  be  able  to  "see,  feel,  touch,  and  taste" 
a  proposed  system.  This,  in  itself,  is  an  educational  experience 
and  can  help  the  user  adjust  to  nev  technology  [283.  Paper 
studies  and  analyses  do  not  promote  this  interaction.  Use  of 
prototypes  can  bridge  the  communication  gap  between  developer  and 
user.  "With  a  prototype,  the  user  can  exercise  the  system  just 
as  though  it  were  already  operating  in  his  own  environment,  and 
thereby  provide  vital  feedback  to  the  developer  on  the 
suitability  of  the  specification”  C293. 

2.  Costs  and  Benefits  of  Prototypes 

Traditional  C2  acquisition  has  shunned  prototypes  mainly 
because  their  cost  is  considered  prohibitive  (301.  Hassan  Gommaa 
of  the  General  Electric  Company  has  concluded  that  prototypes  can 
be  developed  for  lesB  than  10%  of  total  software  cost  C313.  With 
software  cost  comprising  SOX  of  total  C 2  system  cost,  this  means 
prototypes  can  be  developed  for  approximately  8 X  of  total  system 
cost  C323.  This  is  a  small  price  to  pay  to  avoid  developing  a 
system  with  mls-specif led  or  incomplete  requirements.  Errors  in 


requirements  are  usually  the  last  to  be  detected  and  the  most 
costly  to  correct  (333.  Adding  non-monetary  costs  such  as 
degradation  of  C2  systems  vital  to  national  security  (detection 


and  tracking  of  ballistic  missiles  comes  to  mind),  strengthens 
the  case  for  using  prototypes  to  define  and  prioritize 
requirements. 

Prototypes  do  not  have  to  be  full  scale  mock-ups  of  the 
system.  The  Armed  Forces  Communications  and  Electronics 
Association  goes  so  far  as  to  distinguish  a  rapid  requirements 
definition  capability  as  an  entity  distinct  from  a 
prototype  [34].  Semantics  aside,  The  AFCEA  concept  is  what  is 
implied  by  the  word  prototype  in  this  report.  Under  this 
concept,  off-the-shelf  technology  is  rapidly  assembled  to 
simulate  a  number  of  functions  the  user  wants  to  perform.  The 
user  employs  the  capability  to  solve  real  world  problems  and 
provides  feedback  to  the  developer.  This  iterative  process 
refines  the  user's  requirements  to  the  point  where  they  can  be 
adequately  specified  to  contractors  in  a  request  for  proposal. 

The  benefits  of  using  prototypes  include:  (1)  involving 

the  real  user  directly  in  the  requirements  process;  (2)  allowing 
the  real  user  to  adequately  express  his  interoperability 
requirements;  (3)  identifying  incorrect  requirements;  <4) 
identifying  omissions  in  requirements;  (5)  identifying 
ambiguities  in  requirements;  (6)  eliminating  misunderstandings 
between  the  developer  and  user  due  to  different  backgrounds;  (7) 
providing  insight  on  the  proper  system  design;  (8)  facilitating 
user  acceptance  of  new  technology;  (9)  allowing  the  user  to 
evolve  his  procedures  along  with  the  technology  [35]. 


C.  RECOMMENDATION 

Recommendation  3  (aee  pages  23  and  24  for  recommendations  1  and 
2):  Electronic  Systems  Division  should  develop  a  generic  C2 

prototyping  capability  which  can  be  modified  in  response  to 
initial  requirements  in  the  draft  Statement  of  Need.  This 
capability  will  allow  prototypes  to  be  developed  and  installed  at 
the  user's  location  to  iterate  requirements  and  determine 
priorities. 

This  approach  can  be  successful  only  if  ESD  takes  the 
initiative  to  train  and  educate  the  real  user.  ESD  must  also 
involve  the  surrogate  user  because  many  of  the  programmatic 
details  must  still  be  worked  through  him.  It  is  envisioned  that 
the  use  of  prototypes  will  facilitate  communication  between  the 
technologist,  user,  and  surrogate  user.  The  product  of  this 
communication  will  be  well  defined  and  prioritized  system 
requirements.  Furthermore,  exercising  the  prototype  in  the 
user's  environment  should  stimulate  procedural  thinking  and  help 
the  user  evolve  his  concept  of  operations  in  concert  with 


advancing  technology. 


CONCLUSION 


This  paper  makes  a  distinction  between  the  developer's 
role  as  purchasing  agent  and  the  developer's  role  as  supplier. 

The  framework  is  useful  because  it  allows  the  problems  of 
requirement  prioritization  to  be  analyzed  and  it  suggests 
solutions.  In  reality,  the  two  roles  of  the  developer  are 
interwoven  in  the  requirement  process  and  the  concept  formulation 
phase.  Their  separation,  while  useful,  does  not  tell  the 
complete  story. 

Requirement  prioritization  must  take  place  in  an 
environment  that  integrates  the  perspectives  of  all  the 
participants.  Using  the  framework  outlined  in  this  paper  may 
assist  Electronic  Systems  Division  to  reach  out  to  other 
participants  in  the  requirement  process,  but  too  rigid  an 
application  could  also  separate  the  cost  analyst  from  the 
technologist  within  ESD.  In  this  light,  cost  and  technical 
advice  must  remain  coupled  to  help  the  user,  user  surrogate,  and 
other  participants  in  the  requirement  process  determine  their 
priorities. 
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